The present invention relates to the field of intelligent telephony networks, and more particularly to fault handling in an Advanced Intelligent Network Service Switching Point.
Advanced Intelligent Network (AIN) is a telephone network architecture that allows network elements to instantaneously affect the routing or processing of calls based on criteria other than that of simply finding a connection path through the network. Network intelligence is decentralized off of the switch and distributed among intelligent network platforms, referred to as Service Control Points (SCPs) or adjuncts, which will be collectively referred to as SCPs. Switches such as End Offices and Access Tandems that support AIN capabilities are called Service Switching Points (SSPs). The AIN SSP is described in standards document GR-1298-CORE, xe2x80x9cAINGR: Switching Systems,xe2x80x9d Issue 6, November 2000, Telcordia Technologies, which is hereby incorporated by reference.
SCPs typically include data bases in which customer-specific information is stored for use by the network to route or affect the processing of calls. An SCP receives a query message from the SSP when the SSP requires assistance in routing a call and/or providing a feature. The SCP responds to the SSP with routing and/or processing instructions for the call. In AIN, relatively inexpensive peripheral computers can provide flexible and efficient call processing, and carriers can design and release new calling services by modifying the SCP data. SCPs can perform a wide variety of functions, ranging from providing simple instructions or data resources to managing the overall delivery of calling services. AIN also allows for the local SSP to act as feature/service host for these service function applications.
FIG. 1 shows a block diagram of an example of an AIN network. End Offices EO 1-A and EO 1-B are connected to Access Tandems AT 2-A and AT 2-B over voice trunks 5-A and 5-B. AT 2-A and AT 2-B are connected over voice trunk 9. Switches 1-A, 1-B, 2-A and 2-B form a traditional telephone network. Signal Transfer Point STP 3-A is connected to switches 1-A and 2-A over Signaling System 7 (SS7) links 6-A and 7-A. Signal Transfer Point STP 3-B is connected to switches 1-B and 2-B over SS7 links 6-B and 7-B. STP 3-A and STP 3-B are connected over SS7 link 10. Signal Transfer Points are network elements that route signaling messages in the AIN network. Service Control Points SCP 4-A and SCP 4-B are connected to STP 3-A and STP 3-B over SS7 signaling links 8-A and 8-B.
AIN is based on a basic call model that describes the essential processing steps done by an SSP in establishing a two-party call. FIG. 2 shows a portion of the AIN Originating Basic Call Model through sending a call setup indication to the Called Party ID. Each major call step is indicated by a box with a numbered step name inside, e.g., xe2x80x9c1. O_NULLxe2x80x9d, xe2x80x9c7. SEND_CALLxe2x80x9d, etc. Associated with the major call steps are trigger detection points, each indicated by a box with a xe2x80x9cTxe2x80x9d. Each trigger detection point is further identified by a name, e.g., xe2x80x9c(e1) Origination_Attemptxe2x80x9d. Trigger detection points identify when an SCP can receive notification of a given event and influence subsequent call processing. Each trigger detection point typically has several associated triggers that may be set. If a trigger is set at a certain trigger detection point, and the trigger is encountered during the processing of a call and no escape criteria are met, then the SSP will suspend normal call processing and send a query message to the SCP requesting call routing or feature instructions. Upon receiving a response from the SCP, the SSP closes the transaction and resumes call processing per the SCP instructions.
Each AIN trigger is defined by many attributes that describe, for example, where in the call model the trigger is, under what criteria the trigger will be activated, the address of the SCP to which the SSP will send its request message, and fault handling for conditions such as timer expiration or resource failure.
As part of the design of an AIN service, fault handling must be considered. There are generally three categories of faults: protocol errors, application errors, and resource failures.
Protocol errors are caused by incorrect messages received at the SSP from the SCP. Examples include incorrect or unexpected message types, missing parameters, fundamental encoding problems with the message, and unrecognized SS7 TCAP transaction IDs in which the SSP can""t associate the received message to an open transaction.
Application errors are errors that are associated with messages received at the SSP from the SCP that violate the requirements associated with sending the message and are of a non-protocol nature. Examples include response message timer expired, missing conditional parameters, and erroneous data values.
A resource failure occurs when a hardware or software resource within the SCP, SSP, or IP is unable to provide functionality that is necessary for the completion of an operation requested by a message. Examples include link failures, and situations where the SCP is unable to locate an application program requested by an operation.
Within each category of error, there are fatal errors, which are conditions that cause an operation to be unsuccessful and may cause a transaction to be closed, and non-fatal errors, which are error conditions that do not interfere with the completion of an operation. An example of a fatal error would be a voicemail operation where the link to the SCP containing the voicemail functionality is unavailable. In this case, the voicemail operation is aborted. An example of a non-fatal error would be a calling name and number operation where the calling name is not returned. In this case, the calling number can be displayed with, for example, xe2x80x9cnot availablexe2x80x9d displayed for the calling name. The transaction was not successful, but the call was completed.
The present invention is an enhancement to AIN fault handling that allows SSP triggers to access an alternative treatment application when fault handling is invoked. If an alternative treatment application option is referenced in the BCM fault handling attribute, then the application is called when AIN fault handling is invoked. If the alternative treatment application is not successful in completing the service function, then one of the traditional fault handling options is applied, (i.e., routing to a specific directory number, voice announcement then terminate call, continue, or final treatment). The present invention allows a last attempt at completing the service function by the alternative treatment application after fault handling is called, but before default handling or final treatment is invoked.
In an example of the preferred embodiment of the present invention, a toll-free service is supplemented in the SSP with a caching scheme that tracks the last, for example, ten thousand toll-free numbers and their translations that were dialed by subscribers connected to the SSP. In the BCM fault handling attribute of the SSP toll-free service trigger, an alternative treatment application is referenced that will perform a look-up in the cached toll-free numbers. In the event of a link failure to the toll-free service SCP, fault handling will be invoked and the alternative treatment application will be called. If the called toll-free number is in the cached information, the alternative treatment application will return the translated directory number (DN) to the SSP, which will successfully complete the requested toll-free service function. If the alternative treatment application cannot find the called toll-free number in the cached information, then the alternative treatment application returns an error condition, and, in this case, the call is directed to final treatment.